This invention relates to automated banking machines. Specifically this invention relates to an automated banking machine apparatus and system that is operative to independently and simultaneously provide user interfaces at both a consumer and a service display or other multiple user displays.
Automated banking machines are well known. A common type of automated banking machine used by consumers is an automated teller machine (xe2x80x9cATMxe2x80x9d). ATMs enable customers to carry out banking transactions. Common banking transactions that may be carried out with ATMs include the dispensing of cash, the receipt of deposits, the transfer of funds between accounts, the payment of bills and account balance inquiries. The types of banking transactions a customer can carry out are determined by capabilities of the particular banking machine and the programming of the institution operating the machine. Other types of automated banking machines may allow customers to charge against accounts, to transfer funds and/or to cash checks or redeem other types of items. Other types of automated banking machines may print or dispense items of value such as coupons, tickets, wagering slips, vouchers, checks, phone cards, smart cards, food stamps, money orders, scrip or traveler""s checks. For purposes of this disclosure a reference to an automated banking machine or an automated transaction machine shall encompass any device which carries out transactions including transfers of value.
ATMs have been developed which include both a front consumer user station and a rear service or maintenance user station. Each user station includes corresponding front and rear display devices and input devices. The front consumer user station typically includes a front consumer display that is publicly viewable and accessible. The front consumer display is generally associated with input devices such as a keypad and function keys which enable a consumer to perform transactions with the ATM. The rear maintenance user station is typically orientated in a position or location that is only accessible to individuals who maintain or service the ATM. Because the rear user station is generally used for maintenance purposes, it typically includes a rear maintenance display with access to the operating system and maintenance software. The rear maintenance display is typically associated with one or more computer input devices such as a fill keyboard and a mouse device.
In systems with dual displays, the maintenance display (alternatively referred to herein as a rear display) is controlled by the operating system and provides access to a computer shell, window, or other standardized interface to the operating system of the ATM. The consumer display (alternatively referred to herein as a front display) is typically a xe2x80x9cslavexe2x80x9d device that is controlled by a terminal software program using proprietary drivers. If the terminal software program terminates, the proprietary drivers are no longer available to output new consumer screens to the front display device. Consequently, the front display typically goes blank or shows a frozen screen, while the rear display may remain active and responsive to inputs from the associated keyboard and/or mouse.
Because the front screen is a xe2x80x9cslavexe2x80x9d device that is dependent on proprietary drivers for output, a servicer cannot use the front screen to run and interact with conventionally written programs. Only programs that are operatively programmed to access the hardware specific proprietary drivers of the display will have the ability to output a user interface on the front display. Such a design requires a more complex terminal software program with operative low level hardware dependent programming. In addition, if a different display hardware is implemented for the ATM, the terminal control software must be rewritten to interface with the new proprietary drivers that correspond to the new display hardware.
Consequently there exists a need for an ATM with terminal control software that is less complex to develop. There further exists a need for an ATM with terminal control software that can output user interfaces on two or more displays without being tied to specific proprietary display drivers.
The consumer displays of ATMs typically do not have associated input devices such as full keyboards and pointing devices. Any program that can be accessed through the front display must be operatively programmed to accept inputs from more limited input devices, such as keypads, touch screens, and function keys. To enable programs to be accessible from both the front and rear displays, separate front and rear interface programs may be created for dual display ATMs. Each of the front and rear interface programs are written to accept inputs from the specific types of input devices associated with the respective front and rear displays. For example a mouse device has the ability to easily move to and click a specific user interface element placed anywhere on a user interface window. This functionality enables ATM terminal software programmers to use a complex assortment of user interface elements such as scroll bars, buttons, list boxes, hypertext links, text boxes, tab controls, tree views and option buttons. Although such user interfaces are easily manipulated with a mouse at the rear display of an ATM, such user interfaces are very difficult to work with at the front display due to the more limited nature of available input devices such as function keys and keypad buttons.
Thus when a maintenance software program is required to be accessed from the front consumer display of the ATM, a separate front user interface program must be developed which is less complex and more easily accessed by input devices typically found in association with the front consumer display. Developing different user interface programs responsive to different input devices can consume a significant amount of programming effort. Consequently, there exists a need for an ATM programing architecture that reduces the need to develop separate user interface programs for both the consumer and servicer displays of an ATM.
ATM applications have been developed using a plurality of different operating systems such as Microsoft(copyright) Windows(copyright) NT and IBM(copyright) OS/2(copyright). In addition for each targeted operating system more than one type of application development tool or version of the tools may be used. For example with a Microsoft(and Windows(copyright) NT operating system different C++ compilers from Microsoft(copyright), IBM and other tool providers may be used to build ATM applications.
Unfortunately, when developing ATM applications different sets of source code must be written and maintained for each targeted operating system platform and software development tool. Although much of the source code is the same or similar for each targeted platform, incompatibilities between the operating systems platform and the foundation classes of the development tools typically require different sets of source code to be written. Maintaining completely separate sets of source code for each targeted platform decreases the productivity of ATM software developers. Consequently there exists a need for a method for developing ATM applications for different platforms and for different development tools that decrease the amount of duplicate code that must be written and tested.
When multiple developers are working to maintain ATM applications targeted for different platforms, each development workstation must include at least one installation of a development tool that is capable of compiling and building the ATM application. Although it may be desirable to install more than one development tool on a development workstation, in many cases the incompatibilities between different compilers and their configuration on a workstation makes it impractical to do so. Consequently there exists a need for a system of developing platform specific applications which enables a developer of ATM applications to more easily compile an application with different compilers from the same development workstation station.
Also, when more than one developer is working on a common set of ATM source code, there exists the possibility that one developer may be using a different version or configuration of a development tool than another developer. When this occurs, unobvious bugs can be introduced into ATM applications. Although this problem can be solved by having each developer run a shared compiler from a network source rather than from a local hard drive installation, development tools that are run from a network tend to be relatively slow and result in a decrease in programer productivity. Consequently there exists a need for a system for developing platform specific ATM applications that reduces the opportunity for different developers to inadvertently compile a common set of applications with different versions of a compiler.
It is an object of an exemplary form of the present invention to provide an automated banking machine at which a user may conduct transactions.
It is a further object of an exemplary form of the present invention to provide an automated banking machine that may be operated through a plurality of user stations such as either a front user station or a rear user station.
It is a further object of an exemplary form of the present invention to provide an automated banking machine that may provide both a front publicly available consumer display and a rear non-public maintenance display.
It is a further object of an exemplary form of the present invention to provide an automated banking machine with a simplified programming architecture for the development of terminal control software and maintenance software for a multiple display machine.
It is a further object of an exemplary form of the present invention to provide an automated banking machine with terminal control software that does not require hardware specific programming for proprietary display devices.
It is a further object of an exemplary form of the present invention to provide an automated banking machine with terminal control software that does not require multiple user interfaces to be developed for different sets of input devices at the front and rear displays.
It is a further object of an exemplary form of the present invention to provide a method of developing automated banking machine applications for different platforms that reduces the amount of duplicated source code that must be written and maintained.
It is a further object of an exemplary form of the present invention to provide a method of developing automated banking machine applications for different platforms that enables a more practical and productive method of using multiple development tools from the same development workstation.
It is a further object of an exemplary form of the present invention to provide a method of developing automated banking machine applications for different platforms that reduces the risk that multiple developers will accidently build and compile shared source code with different versions of a development tool.
Further objects of the present invention will be made apparent in the following Best Modes for Carrying Out Invention and the appended claims.
The foregoing objects are accomplished in an exemplary embodiment of the invention by an ATM that includes at least two user stations in operative connection with a computer. A first one of the user stations includes at least one publicly available display device and at least one publicly available input device. A second one of the user stations includes at least one non-publicly available display device and at least one non-publicly available input device. In the exemplary embodiment the first user station is generally configured as a consumer user station, where customers of the ATM can perform transaction functions with the ATM. The second user station is generally configured as a service or maintenance user station, where servicers of the ATM can perform maintenance related functions with the transaction function devices and software applications of the ATM. In one exemplary embodiment the first consumer user station is generally located at the front of the ATM while the second maintenance user station is generally located at the rear of the ATM.
The exemplary embodiment of the present invention includes output devices such as a display screen and/or an audio system. The exemplary embodiment further includes input devices such as a touch screen, keypad, mouse, touch pad, trackball, pointer, biometric scanners and/or speech recognition system. The ATM further includes transaction function devices such as a dispenser mechanism for sheets of currency or other sheets, printer mechanisms, a card reader and/or writer, a check or other document readers, a depository mechanism and other transaction function devices that are used by the machine in carrying out transactions. In the exemplary embodiment the computer is in operative connection with each of the output devices and the input devices as well as with the sheet dispenser mechanism, card reader and other physical transaction function devices in the ATM.
Each of the display and input devices for the front consumer and rear maintenance user stations is generally controlled through the operating system of the computer. For one embodiment of the present invention, the input devices for the consumer user station include function keys and a keypad. However, in general a consumer user station may include any input device which allows a consumer to interact with the ATM to perform transactions representative of transfers of value. The maintenance user station of this described embodiment includes other computer type input devices such as a full keyboard and mouse. However, in general the maintenance user station may include any input device that enables a servicer to readily maintain and configure an ATM.
In the exemplary embodiment the operating system is placed in a mode which is operative to output a desktop shell environment which produces a visual field that spans both the first and second display monitors. Such a visual field output is referred to herein as a desktop environment or desktop. The first display outputs a first portion of the operating system desktop environment and the second display outputs a second portion of the desktop environment. This dual monitor feature effectively increases the size of the desktop. When a mouse or other pointer device is moved across the desktop responsive to the physical movement of a mouse device, the corresponding pointer will automatically jump between display devices responsive to which portion of the desktop environment the mouse pointer is located. Regardless of which monitor is outputting a particular window for an application, the application will receive keyboard inputs. Such capability can be used in an automated banking machine to use several discrete display devices to provide a single large output. This can be used to advantage particularly to provide a large consumer display. Compared to the cost of purchasing a single very large monitor, using multiple relatively smaller monitors provides a relatively inexpensive method for increasing the amount of desktop real estate.
Exemplary embodiments of the present invention take advantage of platforms which offer multiple monitors by configuring and orientating the monitors in an alternative manner. Rather than placing monitors adjacent to each other to effectively increase the size of the working display for a single user, the exemplary embodiment may use each display device as a separate user station, with one publicly available to consumers and one privately available to servicers.
In this manner a consumer terminal control software application is operative to output a consumer user interface in the first portion of the desktop being output through a front consumer display device. A maintenance program is operative to output a maintenance user interface in the portion of the second desktop being output by the rear maintenance display device. Even though the computer and operating system of the ATM is outputting a common desktop, a consumer can perform transactions using the consumer user interface on the first portion of the desktop while a servicer can simultaneously perform maintenance functions with the maintenance user interface on the second portion of the desktop.
In the exemplary embodiment when a pointer input device such as a mouse or track ball is connected to the computer adjacent the rear maintenance display, the computer is operatively programmed to prevent the associated mouse pointer display output from moving from the second portion of the desktop to the first portion of the desktop. This behavior is achieved in the exemplary embodiment by employing a software feature referred to as a hook application which processes mouse messages prior to the operating system moving the mouse pointer. When the hook application determines that a mouse input corresponds to a movement of the mouse pointer from the second portion of the desktop to the first portion of the desktop, the hook application is operative to maintain the location of the mouse pointer on the second portion of the desktop. This behavior prevents the outputting of a mouse pointer on the front consumer display. Thus when a servicer is using the mouse with the rear maintenance display, a consumer will not be able to view the mouse pointer.
In exemplary embodiments of the present invention the consumer display device may include a touch screen input device adjacent the front of the display. The touch screen enables a user to generate pointer type input signals by touching or sliding a finger adjacent the device. The previously discussed exemplary hook application may also be used to prevent the mouse pointer from jumping to portions of the desktop that corresponds to the user""s touch screen inputs.
In addition the default behavior of a computer system connected to a touch screen input device is often operative to send a signal to the operating system to move the input focus to the application window being touched. For example if the user at the front consumer display touches a portion of the touch screen that corresponds to a user interface screen, the touch screen may send the operating system a message to give the consumer user interface input focus. When the consumer user interface gets the input focus with a touch screen input, any application a servicer may be using with the rear maintenance display will lose input focus. For example, if a servicer is typing information using a keyboard into a maintenance user interface, all keystrokes will be lost when the input focus switches to the consumer user interface.
The exemplary embodiment solves this problem by being operatively programmed to monitor events which move the input focus to a consumer user interface application. When such events occur, the computer is operatively programmed to automatically return the input focus to the maintenance user interface application which previously had the input focus. In one exemplary embodiment this functionality is achieved by using a hook application like that previously mentioned in connection with mouse messages. In other exemplary embodiments, consumer user interface applications are operatively programmed to invoke a return focus method in response to receiving the input focus.
The exemplary embodiment of the present invention is operative to display corresponding user interface windows for an application on either the rear maintenance screen or the front consumer display. This feature enables a servicer to perform maintenance operations with a maintenance application while standing adjacent either the front display or rear display of the ATM. In some machines transaction function devices are maintained and serviced at the rear of the machine. However, the ability to test and diagnose problems with transaction function devices from the front of the ATM is beneficial. For example by standing at the front of the ATM, the servicer can test the dispensing ability of a cash dispenser or printer. The servicer may also test the input ability of devices such as a card reader or depositor. By operating maintenance software from the front consumer display the servicer can better diagnose and repair problems from the perspective of a consumer. Also in machines that have consumer displays and maintenance displays on the same side of the machines there are situations in which it may be advantageous for a servicer to perform service functions using the customer display and input devices.
Unfortunately, many consumer input devices are not of the same type or do not have the same capabilities as input devices adjacent the maintenance display. For example, a mouse or other pointer device is not typically available to a servicer at the consumer display of the ATM. Thus a maintenance user interface that includes user interface elements such as drop down list boxes and scroll bars would be very difficult to use with consumer input devices such as function keys.
One approach to solving this problem is to write a separate maintenance application with a user interface that corresponds to input devices for either the consumer or maintenance user station of an ATM. However, such an approach may double the amount of maintenance software that is required to service an ATM. The exemplary embodiment of the present invention includes a software architecture that reduces the need to write separate user interfaces for different combinations of input devices. User interfaces developed in the exemplary embodiment employ documents which include hardware independent command instructions for generating user interface elements. These instructions are interpreted differently by a document viewer user interface program responsive to the input devices associated with the particular user station that are used to interact with the user interface.
For example a command instruction to generate a command option is interpreted by the document viewer at the rear maintenance display as a mouse clickable button. However, the same instruction for the consumer display is output by the document viewer as a function key indicator which points to which physical function key is operative to trigger the command option. Examples of such a programming architecture for automated banking machines is shown in U.S. patent application Ser. No. 09/233,249 which is incorporated herein by reference in its entirety as if fully rewritten herein.
In the exemplary embodiment software applications for performing maintenance tasks with the automated banking machine include hardware specific functions which are decoupled from the user interface documents. In this manner the user interface portions of the software and the hardware specific functions can be independently developed and maintained. In the exemplary embodiment the user interface documents include XML formatted command instructions which define features of the user interface. The hardware functions are placed in event processor DLLs which are called by the document viewer in response to a user interface event. The user interface command instruction in addition to defining features of the user interface also specifies which event processors are to be called in response to user interface events.
The exemplary document viewer is operative to output a corresponding user interface for the front and rear displays responsive to the types of input devices that are available adjacent thereto or which are designed to be operatively interactive therewith. This feature enables a developer of ATM software to concentrate on the features of the user interface without lost time developing different versions of the user interfaces for different types of input devices. Thus a developer can implement a single document with command instructions that define the desired functionality of a user interface. The exemplary document viewer responsive to this single document will generate different user interfaces based on the capabilities of the display and associated input devices. In the exemplary embodiment the document viewer is configured with a listing of which input devices are associated with which display device. The user interfaces are generated responsive to this input device configuration listing.
In addition the exemplary embodiment of the present invention is further operative to simplify the development of language specific user interfaces. In general, automated banking machines have included different sets of user interface screens for each human language that is desired for the ATM. Any changes in layout or functionality to the user interface require that each alternative language specific user interface be updated as well. The exemplary embodiment is operative to simplify this process by associating identification values with each user element defined in a user interface document. Such documents also include text labels for individual user interface elements which may be in a default language such as English. The exemplary process simplifies translations by substituting command instructions with labels in one human language for corresponding command instructions with labels in another human language based on a determination of matching identification values.
In one exemplary embodiment the alternative command instructions with translated labels are saved in language specific documents with the same name as the primary document but located in language specific subdirectories. When the document viewer generates a user interface, it is operative to determine a target language for the user interface. The document viewer then locates at least one alternative language document which may have the same name as the primary document. The document viewer then substitutes all command instructions in the default language of the user interface document with corresponding command instructions in an alternative language document based on matching ID values. Alternative embodiments may employ other methods of storing associated alternative language labels, including placing the alternative language labels in the primary document.
The exemplary embodiment of the present invention is designed to be backward compatible with prior art ATMs. In particular the exemplary embodiment is operative to generate a consumer user interface responsive to escape code sequences received from a remote host computer which define the layout and functionality of the consumer user interface. In prior systems the terminal control software drives the output of a xe2x80x9cslavexe2x80x9d display device responsive to the escape code sequences. The exemplary embodiment is operative to output the consumer user interface by generating the user interface on the portion of the desktop being output through the consumer display. By taking advantage of high level drawing libraries of the certain operating systems, the present invention eliminates the need to write code targeted to specific proprietary slave drivers. In embodiments of the present invention that run on a Windows(copyright) 2000 type platform, high level interfaces such as Direct Draw and Direct Show can be used to generate the consumer user interface. Consequently any graphics board, video board, MPEG hardware or other display device that includes Direct Draw and Direct Show drivers may be used with the exemplary terminal control software to generate consumer user interfaces.
In systems with xe2x80x9cslavexe2x80x9d consumer displays, when the terminal control software exits prematurely or locks up, the consumer user interface becomes inoperative. However the default behavior of dual monitor configurations is that if the terminal control software exits prematurely, the background of the desktop may be visible and accessible by users of the consumer display. This behavior may be undesirable for ATM applications. Consequently the exemplary embodiment includes a blank screen application that is operative to independently generate a blank screen which covers the area of the desktop being output by the consumer display device. In one exemplary embodiment the blank screen output is located in a layer that is between the consumer user interface and the desktop, such that when the user interface is shut down or terminates, the blank screen will be the top application and will hide the desktop.
In other exemplary embodiments the blank screen application is operative to receive screen data from either the terminal control software or maintenance application software. The blank screen application generates a corresponding consumer or maintenance user interface responsive to the screen data on the portion of the desktop being output by the consumer display. When the terminal control software exits, the blank screen can be sent an exit message which prompts the blank screen application to display a blank user interface with a message indicating that the ATM is out-of-service. Also when the maintenance application requires the ATM to be taken offline, the maintenance application is also operative to send the blank screen application a message which prompts the blank screen application to display a similar out-of-service message with the consumer display device. Further embodiments of the present invention are operative to receive escape code sequences from a host corresponding to outputting unicode fonts, palettized windows, MPEG videos, HTML documents, and other multimedia files or indicia that can be output on a portion of the operating system desktop.
The exemplary embodiment of the present invention may be used in conjunction with a method of building and compiling ATM source code that is targeted for different platforms. Rather than having each development workstation include one or more local copies of different types and versions of development tools, in the exemplary embodiment the compiler for each development tool is organized and stored on a separate removable medium such as a CD-ROM, Zip disk or any other portable storage device.
When the developer wishes to compile ATM source code, the workstation is placed in operative connection with the portable medium and a configuration script for the particular type and version of the compiler is executed. The configuration script modifies the workstation in a manner which enables the workstation to run the compiler from the portable medium. When a new compiler is required, the original portable medium is rendered operatively disconnected from the workstation and a second portable medium with the new compiler stored thereon is placed in operative connection with the workstation. The corresponding configuration script for the new compiler is executed on the workstation enabling the workstation to compile ATM source code using the new compiler on the second portable medium.
For example, in one exemplary embodiment, a Microsoft(copyright) C++ compiler is stored on a first CD in such a manner than it may be executed from one or more workstations after running a corresponding first configuration script. In addition an IBM C++ compiler is stored on a second CD in such a manner that it may be executed from one or more workstations after running a corresponding second configuration script. When developers wish to compile ATM source code with any one of the compilers, they must place the desired CD into their workstation""s CD reader and run the corresponding configuration script.
In the exemplary embodiment each compiler from each CD or other portable medium is executed responsive to a standard make instruction set. The standard make instruction set is adapted for use with a plurality of different targeted ATM platforms and versions of development tools. Thus the standard make is operative to have the compiler include the correct set of libraries that correspond to the targeted platform or version of development tool. In this manner the platform specific code is separated into independent libraries from the common source code that is compatible with each platform. Consequently ATM developers are enabled to generate common source code for a plurality of different ATM platforms. When the targeted application is compiled, the standard make file is operative to make sure the correct platform specific libraries are linked and integrated into the desired platform specific distribution of the ATM application.